@dzhdanNV just an observation you nearly have a pure C interface any reason for the C++ code to abstract across that. you can also just union a bunch of stuff together for dx12/dx11/vulkan/metal. You also have all this logic to build tables of functions etc ... avoid having to use a C++ so it should be easier to distribute. I guess you could just access that data based on the api.

struct CmdBuffer {
   union {
      struct {...}dx11;
      struct {...}dx12;
      struct {...}metal;
   };
}

struct NriDevice {
   union {
      struct {...}dx11;
      struct {...}dx12;
      struct {...}metal;
   };
   int (*Method1)(NriDevice*...);
}

been busy with something else, I'll have to catch up to this once i finish up what i want to do with this game project im working on.

Sure, no prob. And tons of thanks for working on native Apple support!

Thanks for the progress. Very appreciated.

so i guess you encode the data to an argument buffer. I guess to reproduce descriptor sets the pool would allocate an argument buffer for n number of descriptor sets?

fragmentShader(       RasterizerData            in                 [[ stage_in ]],
               device FragmentShaderArguments & fragmentShaderArgs [[ buffer(AAPLFragmentBufferIndexArguments) ]])

To be honest I don't follow. Please, explain the problem and a solution. Is the question about indirect drawing or something else?

I guess to reproduce descriptor sets the pool would allocate an argument buffer for n number of descriptor sets?

Correct. Metal requires to fill argument buffers even for non-indirect draw calls, so you need to store descriptors in it.

any clue how these properties line up with DescriptorRangeDesc?
https://developer.apple.com/documentation/metal/mtlargumentdescriptor?language=objc

for(size_t r = 0; r < descriptorSetDesc.rangeNum; r++) {
            MTLArgumentDescriptor* argDescriptor = [MTLArgumentDescriptor argumentDescriptor];
            const DescriptorRangeDesc* range = &descriptorSetDesc.ranges[r];
            argDescriptor.arrayLength = range->descriptorNum;
            argDescriptor.access = MTLBindingAccessReadWrite;
            argDescriptor.index = range->baseRegisterIndex;
            switch(range->descriptorType) {
                case DescriptorType::TEXTURE:
                    argDescriptor.dataType = MTLDataTypeTexture;
                    argDescriptor.textureType = MTLTextureType2D; // descriptor type does not have this
                    break;
                case DescriptorType::SAMPLER:
                    argDescriptor.dataType = MTLDataTypeSampler;
                    break;
                case DescriptorType::CONSTANT_BUFFER:
                case DescriptorType::STORAGE_TEXTURE:
                case DescriptorType::BUFFER:
                case DescriptorType::STORAGE_BUFFER:
                case DescriptorType::STRUCTURED_BUFFER:
                case DescriptorType::STORAGE_STRUCTURED_BUFFER:
                    argDescriptor.dataType = MTLDataTypeStruct;
                    break;
                case DescriptorType::ACCELERATION_STRUCTURE:
                    argDescriptor.dataType = MTLDataTypePrimitiveAccelerationStructure;
                    break;
            }
        }

An obvious suggestion: you can look at MoltenVK sources and work this way:

NRI => open NRI/VK => open corresponding place in MoltenVK => analyze, rearrange, copy & paste to MTL implementation

(looking at MTL docs...)

An obvious suggestion: you can look at MoltenVK sources and work this way:

NRI => open NRI/VK => open corresponding place in MoltenVK => analyze, rearrange, copy & paste to MTL implementation

(looking at MTL docs...)

I've been looking at the MoltenVK source, thanks for the suggestion. umm, ill have to do a bit of research i don't want to have to extend DescriptorType. maybe there is a more ideal solution?

Why do you need to potentially extend DescriptorType? Because of this:

                case DescriptorType::TEXTURE:
                    argDescriptor.dataType = MTLDataTypeTexture;
                    argDescriptor.textureType = MTLTextureType2D; // descriptor type does not have this
                    break;

?

Why do you need to potentially extend DescriptorType? Because of this:

                case DescriptorType::TEXTURE:
                    argDescriptor.dataType = MTLDataTypeTexture;
                    argDescriptor.textureType = MTLTextureType2D; // descriptor type does not have this
                    break;

?

https://developer.apple.com/documentation/metal/mtltexturetype

defines 1D/1DArray/2D/2dArray/Cube/CubeArray etc ... ill have to see NRISamples when I get there. just something to note later on. Ummm, I still need to finish metal cmd buffers.

You can do the same trick as here -

You can do the same trick as here -

NRI/Source/D3D11/DescriptorD3D11.hpp

Line 55 in 205cf05

switch (textureViewDesc.viewType) {

Just identify your texture type by texture parameters, that's all you need.

in what way?

AFAIK, MTLTextureDescriptor is a direct analogue of NriDescriptor, so it shouldn't be hard to identify the texture type when creating the descriptor. If I'm right, you can use TextureViewType to identify the MTLTextureType.

The problem is that there are no descriptors in DescriptorRangeDesc. In other places - yes. In this and hopefully the only one place - no.

https://github.com/KhronosGroup/MoltenVK/blob/1d2ec638532268d076a550262df2e5e5e4fd2c9e/MoltenVK/MoltenVK/GPUObjects/MVKDescriptorSet.mm#L1146C43-L1146C67
This type doesn't seem to be very important, as it's only used for size calculations.

Same here - https://github.com/KhronosGroup/MoltenVK/blob/1d2ec638532268d076a550262df2e5e5e4fd2c9e/MoltenVK/MoltenVK/GPUObjects/MVKDescriptor.mm#L486